AWS移行～移行を成功させるタスクリスト作り
こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きなネクストモード株式会社 の吉井です。
AWS移行を計画しているお客様から「標準的なタスクリストはないか？」「何から手を付けてよいか教えてほしい」といったお問い合わせを頂戴することがあります。
そのようなお問い合わせに少しでも役に立てるようリストしてみました。
このタスクリストをベースに肉付けやブレークダウンをしていけば、それなりなWBSが出来ることと思います。
目次
ゴール設定
古くから「段取り八分」という通り、ITプロジェクトも段取りが肝です。
ゴール設定は段取りのうちです。
AWS移行の意義や目的を明確にする
AWS移行によって得られる効果は何でしょうか。 最新技術の導入、コスト削減、伸縮性、CI/CDの導入、運用自動化の実現など様々な効果が見込めます。意義や目的を明確にしておきましょう。
いつまでに何を完了させるのか、スケジュールを決定する
フェーズレベルの大まかなスケジュールで構いません。
最終的なゴールから逆算してスケジュールを決定します。
フェーズごとのアウトプットを決定する
意味あるアウトプットを定義します。
あるフェーズのアウトプットは次のフェーズのインプットになるよう定義します。
フェーズごとの体制、役割を決定する
フェーズのアウトプットを正しく出すための体制と役割を決定します。
自社で全てを完結しなくても大丈夫です。必要に応じてAWSパートナーのリソースを活用します。
現状構成の洗い出し
現状構成の理解を深めることがAWS移行成功の鍵になります。
この項目も段取り八分のうちです。
対象とするシステムや機器を明らかにする
移行対象を明確にすることは今後の議論を進めていくうえで重要です。
対象に抜け漏れがあると移行計画自体が進まなくなる可能性もあります。
必要な情報を収集します。
- 機器名称
- 役割
- ホスト名
- サーバースペック
- OS (バージョンも含める)
- ミドルウェア (バージョンも含める)
- アプリケーション (バージョンも含める)
- 直近3ヶ月のパフォーマンスメトリクス
- サーバー間の依存関係
移行対象としないシステムや機器についても同様です。
AWSとオンプレミスの接続などアーキテクチャに大きく影響してきます。
オンプレミスサーバーの情報を自動収集するツールがAWSから提供されているので、これを活用することも検討します。
AWS Application Discovery Service (ADS)
アプリケーション間のデータフローを明らかにする
アプリケーション間のデータフロー、依存関係を明らかにすることがAWS上のアーキテクチャを構成する際の助けになります。
サーバーレス、マイクロサービス、マネージドサービス、疎結合、ステートレスなどのクラウド最適化を検討する際にデータフローの有り無しで成果が大きく変わります。
ビジネスインパクト観点で優先度を付ける
移行対象に優先度を設定します。
色々な要素があると思います。正解は無いので自社のモノサシで判断します。
- 戦略的、技術的な優先度
- デプロイを高速化して自社サービスの競争力を強化したい
- 自社要員の運用負荷が高まっており自動化によって負荷をさげたい
- 最新技術を導入してエンジニアのモチベーションを向上させたい
- 既存IT資産の制約
- 既存契約データセンターの契約期限が迫っている
- 既存ハードウェアの保守切れが迫っている
- レガシー技術の廃止が決まっている
- セキュリティの強化
- 外部攻撃を受けておりAWSで対策を強化したい
- 既存契約のハウジングサービスではセキュリティ要件を満たせない
優先度と依存関係からサーバーをグルーピングする
AWSとオンプレミスのハイブリットになる場合、レイテンシーの問題、接続性の問題等が発生しないよう依存関係のあるサーバーはまとめて移行します。
ハイブリットや順次移行を計画している場合はグルーピングを適切に行うことが大切です。
自社要員のスキルセットを明らかにする
AWS移行するということは自社要員のスキルセットもオンプレミスとは異なるものになります。
クラウド最適化されたアーキテクチャを構築するためにも、運用を自動化して効率化していくうえでもAWSスキル習得は必須です。
AWS公式トレーニングを受講したり、AWSパートナーにレクチャーを依頼するなど外部に頼る方法も検討するためにも現時点でのスキルセットは明らかにしておきましょう。
AWS Migration Readiness Assessment (MRA) というツールがAWSから提供されています。
社組織のクラウドに対する準備状況を評価することが可能です。
いくつかの質問に答えていくと分析されたレポートが出力されます。
今のところ、AWS本体かAWSパートナーの支援が必要なツールとなっているようです。興味があれば何れかに相談ください。
簡易版が提供されているので、気になる方はまず簡易版をお試しください。
https://cloudreadiness.amazonaws.com/#/cart
移行ワークショップ開催
ワークショップを開催します。
AWSに対する理解が個人個人で異なる場合、知識や用語の統一をここで行っておきます。
例えば、「S3にファイルを保管して」といった議論をするにしても、S3に詳しい人と全く知らない人とでは思い描いているイメージが異なり、そもそも議論にならないことが発生すると不幸です。
ワークショップは社内でAWSに詳しい人(いわゆるCCoE)が主導したり、AWSパートナーを招いて開催します。
ファンクショナルデザインワークショップ
アプリケーション機能、業務面から現状構成とAWSを比較し、「こういうサービスを使うと利点がある」という検討をします。
AutoScaling構成をとりたいのでアプリケーションをストートレスにしよう、1機能1サーバーの原則に従い機能を分割しよう、といったことを検討します。
テクニカルデザインワークショップ
インフラ面から現状構成とAWSを比較し、「こういうサービスを使うと利点がある」という検討をします。
監視はCloudWatchに寄せる、バックアップサーバーは廃止、RDBMSはRDSを使うなどテクニカル要素の検討を行います。
マイグレーションデザインワークショップ
データコンバージョン、サーバーインテグレーションなど移行方式をします。
AWSにはSMS、DMS、SCT、ADS、Migration Hub、CloudEndure、VM Import/Export といったマイグレーション支援ツールがあります。
ツールを使った効率的な移行方式を検討します。
セキュリティデザインワークショップ
自社のセキュリティ要件、社内規定、業界標準など収集し
AWSのどのサービスを使って規制をかけるのかを検討します。
AWSのセキュリティ系サービスは充実しています。フル活用しましょう。
デプロイ・プロビジョニングワークショップ
インフラリソースやアプリケーションのデプロイ方式をクラウド最適化することを検討します。
アプリケーションの制約がある場合は平坦な道のりではないと思いますが、思い切って新しい技術を取り入れてみることをお薦めします。
運用モデルワークショップ
現行運用ドキュメントを見ながら、AWSで改善・省力化できる箇所を検討します。
AWS移行を契機にモダンな運用モデルを取り入れて、システムにも担当者にも優しい運用を目指します。
あるべき像の定義
叩き台になる「理想のアーキテクチャ」を作成する
ワークショップで検討、議論、勉強した知識から仮の構成図を作成します。
最初の実現度は70～80％程度でも大丈夫です。
叩きながら完成を目指します。
叩き台に対して実現性を議論する
叩き台となるアーキテクチャをベースに実現性を議論します。
仕様上の無理がないこと、アプリケーション改修が発生する場合は人的・時間的に無理がないことを確認します。
知見の無い技術に対しては技術検証を計画します。
データ移行方式案を作成する
継続的データ同期を採用して停止時間を最小にするのか、
静止点を確保して確実なデータ移行を行うのか、
2つを組み合わせてより良い移行方式を採用するか、様々な方式から選択します。
スキルが不足している部分は要員トレーニングの計画を立てる
アーキテクチャの実現性を議論していていると、スキル不足も浮き彫りになってくると思います。
不足している部分はトレーニングを実施しスキル習得を目指します。
AWSやAWSパートナーの外部トレーニングは有用です。
AWSは自習型のワークショップやBlackbelt、リファレンスアーキテクチャ、ベストプラクティスが多く用意されています。外部受講せずともスキル習得は可能です。
AWSスキルだけではなく、プロジェクトマネジメントやITILなど幅広く計画しておくと役に立つと考えます。
課題抽出
あるべき像が固まった段階で、実現性が不透明な事項、移行を阻害する事項、 決めておかなければならない事項を洗い出し、影響度と緊急度を定義します。
移行戦略の策定
段取り八分の最終段階です。
PoC (概念実証)、技術検証の計画
抽出した課題のうち技術的課題を解決するための技術検証を行います。
解決できない場合は代替案を検討することになります。
要員トレーニング実施
計画したトレーニングを実施します。
効果的なトレーニングになることを祈っています！
移行対象の決定
移行対象を確定します。
これまでのタスクのなかで移行対象の絞り込みは完了しているはずです。
ここでは初期費用・月額費用を算出するために対象を確定します。
カットオーバー要件定義
移行にさいして制約や前提条件を掘り起こします。
移行期間中の停止許容時間、切り戻し条件、現行システムを稼働していられる最終期限なども定義しておきます。
マスタースケジュールの作成
これまでのタスクで全体的なスケジュールが見えていると思います。
マスタースケジュールとしてドキュメントにまとめておきます。
費用の算出
AWS利用料金の算出をします。
Savings Plans などの割引も考慮にいれます。
追加ソフトウェアが必要な場合は初期費用と保守費用を見積もります。
設計フェーズ以降で外部ベンダーの協力を得る場合は作業費用を見積もります。
カットオーバー後のシステム運用を外部ベンダーへ委託する場合は初期作業費用と月額費用を見積もります。
技術検証
検証計画に従って検証を行います。
可能な限り本番環境に近い環境で行うと良い結果が出ると思います。
検証結果を評価できるように各種メトリクスを取得しながら行います。
検証実施後は評価を行います。
事前に設定したKPIを満たしているか、ファンクション実装に問題はないか、継続的な運用に無理がないかなど、本稼働を想定して関係者で評価します。
設計
これ以降は一般的なITシステムでのタスクになりますので皆様よくご存知の工程になるかと思います。
要件定義
現行システムがある前提なので、ゼロから要件を掘り起こす必要はないと思いますが、AWSへ移行して変更になる要素があるはずなので今一度要件は整理しておくと良いと思います。
アーキテクチャ設計
ベストプラクティスが凝縮された AWS Well-Architected を参考にして設計を行います。
AWS Well-Architected フレームワークにはAWS上でシステムを効果的に稼働させるための設計原則や概念が記載されています。
この設計原則に従うだけでのかなりの効果が得られるはずです。
パラメーター設計
AWSリソース、OS、ミドルウェア、アプリケーションなどのパラメーターを決定します。
パラメーターを事前に決めてから構築するのではなく、構築やテストをしながら微調整していくことをお薦めします。
構築
インフラストラクチャは可能な限りコード化しましょう。
再構築や複製が容易な状態で構築することが理想です。
技術者は一般的に手戻りを嫌いますが、クラウド構築は手戻り覚悟のうえで回転率を上げて行うように頭を切り替えます。
テスト
テスト設計
テストの種類(単体、結合、システムなど) と目的、範囲を定義します。
技術的リスクやツールを考慮して、テストの幅と深さを計画します。
テスト実施の制約があれば影響と対策を明示しておくとよいと思います。
繰り返しテストが実施できるようテストデータを用意します。
テスト実行
テストシナリオを作成しテストを実行します。
シナリオは何度も繰り返し実行可能、かつ、自動処理可能なものにしておくと効率的です。
テスト結果レビュー
各種テスト結果を関係者でレビューし合否を判定します。
移行
移行計画の立案
具体的な手順、担当者、日程を決めます。
必要に応じて、他システム連携停止などの調整を行います。
移行手順書には切り戻し手順を含めると安心です。
移行リハーサルの実施
移行手順・工程を作成し手順通りのリハーサルを実施します。
所要時間を計測しておき、許容可能な時間で収まることを確認します。
手順通り進まなかった箇所は修正し、修正した手順でリハーサルを実施します。
計画段階で移行リハーサルは複数回予定しておくのがよいと思います。
カットオーバー
ここまで来たら自分達を信じてカットオーバーを完遂させましょう。
システムのカットオーバーはエンジニアにとって大きな経験値になること間違いありません。
タスク以外のこと
AWS移行するにあたって気を付けなければならないことは何ですか？という質問があります。
一言で答えるのは難しいですが、AWSベストプラクティスを正しく理解して正しく実践することが成功の第一歩だと思います。
自社要員のAWSスキルが満足ではない場合、ワークショップや勉強会、トレーニングを厚めに実施することで知識・用語・目標の統一を実現します。
知らないこと解らないことを少なくするとプロジェクトに対するコミットメントが高まると感じています。
効果がでるので是非お試しください。
設計以降はどれだけ俊敏性を持って進めていけるかが楽しいところではあるので
発想は柔軟に、動きは素早くするような体制作りをしていくことも大切だと思います。
参考
AWS Cloud Adoption Frameworkで作成するクラウド導入ロードマップ
AWS への移行
AWS クラウドサービス活用資料集トップ
以上、吉井 亮 がお届けしました。
![[アップデート] Amazon QuickSight へロゴやテーマカラーを設定するための「ブランド管理機能」が追加されました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-19e77b9a51519e08b94d0f688c125729/4f439c75e1ee56c70e315fa46fa45f81/amazon-quicksight)
